home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 14527 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Memory problems
  5. Date: 15 Apr 1996 08:43:01 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4ktqq5INN6k@keats.ugrad.cs.ubc.ca>
  8. References: <4kt3rc$2nn@nntp.dlsu.edu.ph>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4kt3rc$2nn@nntp.dlsu.edu.ph>,
  12. humprey c. sy <humprey@ccslinux.dlsu.edu.ph> wrote:
  13. >Kindly instruct me on what to do with this problem:  We have this 
  14. >large project in our class which involves programming in C.  Our problem 
  15. >here is we can't integrate our individual codes together, because the 
  16. >program somehow gets so large that it would usually hang.  Individually, 
  17. >each of these code segments are running perfectly well.  I believe this 
  18. >is a memory problem, isn't it?  Any help would be greatly appreciated.  
  19. >Thank you very much!
  20.  
  21. The answer is not necessarily ``you are running out of stack'' as the other
  22. poster implies, but ``you need to adapt sound software engineering practices''.
  23.  
  24. Without these practices it is difficult to carry on a team project, as you are
  25. discovering.
  26.  
  27. How do you know that the individual components run perfectly well? What sorts
  28. of individual tests are you subjecting the various components to? 
  29.  
  30. A runaway pointer in one module can easily bugger up others.  One module can
  31. use another in a way that is not covered by an individual test case, and
  32. trigger a flaw. There may be a memory leak somewhere which will cause the
  33. program to use more and more memory. A simple test strategy may not uncover
  34. this readily: leaks and pointer problems occur even in production systems
  35. produced by experienced programmers.
  36.  
  37. Or you _could_ simply be running out of memory. (Assuming you are working in a
  38. 16-bit environment) your program could simply be requiring resources that such
  39. a computing environment is not sufficient to give. To solve this, you either
  40. move to a more powerful operating system (or at least a DOS extender), or you
  41. rethink some of the data representations in the program that are wasting
  42. space.
  43. -- 
  44. I'm not really a jerk, but I play one on Usenet.
  45.